Automatic determination of correct IP address for network-connected devices

ABSTRACT

An automatic reconfiguration system for industrial networked devices. The system facilitates use of TCP/IP networks, such as Ethernet, as an alternative for industrial fieldbus or device buses by removing the need to perform significant reconfiguration of devices such as I/O modules, sensors, or transducers under field replacement situations. In one embodiment the invention uses a monitor agent to track the IP and MAC addresses of networked devices as well as port information. If a device fails, maintenance personnel make an in-field replacement of the failed device and the monitor agent automatically reassigns the correct IP address to the replacement device.

RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.09/614,489, filed Jul. 11, 2000 which is herein incorporated in itsentirety by reference.

FIELD OF THE INVENTION

The present invention relates generally to networked devices. Morespecifically, the present invention relates to a system of assigningaddresses to network devices, and more specifically, to a systemencompassing automatic assignment of a network address after in-fieldreplacement.

BACKGROUND

Industrial devices such as temperature or pressure sensors are accessedby a client using an Internet Protocol (IP) Address or domain namesystem (DNS) symbolic name (machine.company.com). If a unit needs to bereplaced, the replacement must appear to have the same IP Address as thepredecessor to allow operations to proceed automatically. Typicalmaintenance personnel are not qualified to manipulate IP Addresses andmust defer to Information Systems (IS) department or other networkspecialists. This causes a significant delay in connecting devices,which results in factory down-time. Alternatively, expensive specialistsmust be maintained around the clock to handle such problems.

The state of the art encompasses several networking techniques. TheBootstrap Protocol (BOOTP) is an established method for assigning IPaddress and other key networking parameters to a device where the onlyinformation known about the device is its Ethernet Media Access Control(MAC) address. The protocol was invented by Sun Microsystems in 1985 tosupport diskless UNIX workstations. It is available as an option on mostsoftware products intended for use in embedded (no operator terminal)applications.

The Dynamic Host Configuration Protocol (DHCP) is a standard fornetworking communications. DHCP is a compatible extension to BOOTP andqueries in DHCP form can be generated by devices using modern operatingsystems such as Windows CE or LINUX.

DHCP is primarily used for laptop computers or office systems in largecompanies where the addresses are ‘leased’ for a period of time ratherthan being assigned indefinitely. Likewise, the Simple NetworkManagement Protocol (SNMP) is intended to allow Network Administratorsto find and adjust key networking parameters on devices alreadyinstalled on a network, particularly the routers, bridges, and hubswhich form the infrastructure of the network. The JetAdmin NetworkPrinter tool is a Hewlett-Packard system for reporting printer errorsand administrating usage.

Reverse Address Resolution Protocol (RARP) is an older protocol thanBOOTP and intended for devices that did not require any configurationother than the IP address assignment. RARP is not as widely used asBOOTP because the tools to implement RARP are not as commonplace. RARPis implemented on some embedded system protocol stacks, wherein thesupervisory server may respond with a RARP response if interrogatedusing a RARP request for a given MAC address.

The MAC address is a key identification parameter of all devices on anetwork such as Ethernet. It is a 48-bit number that combinesinformation about the vendor and a unique unit sequence number, and ispermanently allocated by the manufacturer of the network interfaceitself. It is not normally related in any way to the serial number orsimilar representation that a device might require for other reasons.The MAC address is conventionally expressed as a hexadecimalrepresentation that is hard for non-specialists to handle. The Ethernethardware uses the MAC address to determine which network messages areintended for specific delivery (unicast) to this station.

Internet Control and Management Protocol (ICMP) Echo Request, commonlyreferred to as PING is another Internet protocol used for periodicinterrogation of an IP device as an alternative to repeated use of theAddress Resolution Protocol (ARP) request. There is little practicalbenefit for using PING, as the ARP messages are faster and lessintrusive. All modern IP devices will respond to an ARP request becauseit is the only way to determine the MAC address.

An ‘Ethernet Switch’ or ‘Layer 2 switch’ is a device that transmitsmessage packets unchanged from one of its ports to another, using rulesthat are dependent only upon the destination MAC address of the message.Such devices are becoming the preferred interconnection devices forlarge Ethernet networks, since they do not require significantconfiguration. This is as opposed to ‘routers’, otherwise known as‘Layer 3 switches’.

A ‘Managed Ethernet Switch’ is an Ethernet switch which includes amanagement entity conforming to the reporting requirements of RFC 1493,and which therefore specifically may be interrogated to determine whichport of the device was used recently to receive a message from aparticular MAC address.

The protocol exchanges between the system components, namely the device,the managed switch, and the target IP unit are structurally defined invarious standards documents. Software designers refer to thesespecifications when trying to implement software that encodes or decodesvarious messages. The Internet Request for Comment (RFC) documents arethe standard form of documents for all communications using the Internetor TCP/IP.

The following table defines the primary applicable Internet protocolmessages: TABLE 1 SNMP Findport ARP Request ARP Response Request SNMPFindport BOOTP Request See RFC 826 See RFC 826 See RFC 1493/1157Response See RFC 951 BOOTP Response Message type = Message type =Message type = Message type = Message type = Message type = addressaddress resolution SNMP get object SNMP get object BOOT protocol BOOTprotocol resolution request response requested request response requestresponse IP Address Desired IP Resolved MAC Object ID = Object ID =Requesting MAC = Requesting MAC = address = 32 bit address = 48 bit.1.3.6.1.2.17.4.3.1.2. .1.3.6.1.2.17.4.3.1.2. 48 bit MAC 48 bit MAC IPaddress (e.g.: MAC address (e.g.: (MAC as 6 decimal (MAC as 6 decimaladdress (e.g.: address (e.g.: 1.2.3.4) 01:23:45:67:89:ab) number 0-255)number 0-255) 01:23:45:67:89:ab) 01:23:45:67:89:ab) Object value =Assigned IP = port number, or 0 32 bit IP if not found Address

Alternatively, other Internet protocols messages are: TABLE 2 PINGRequest DHCP Request DHCP RARP Request See RFC 792 PING Response See RFC2131/2132 Response See RFC 903 RARP Response Message type = Message type= Message contents = Message Message type = Message type = ICMP ECHOICMP ECHO same as BOOTP contents = reverse address reverse addressrequest response same as BOOTP resolution request resolution responseMessage data MAC = 48 bit MAC MAC = 48 bit MAC unimportant address(e.g.: address (e.g.: 01:23:45:67:89:ab) 01:23:45:67:89:ab) Assigned IP= 32 bit IP Address (e.g.: 1.2.3.4)

There have been numerous attempts to provide an automatic addressingsystem. Many of the existing systems employ non-IP means to set theaddress in advance, such as manually alterable switches, specialconnectors, front panel interface for manually entering addresses, andseparate serial port interface for issuing an address. Although theseexisting means are satisfactory in some instances, they do notadequately address the industrial or factory market for devices such assensors and I/O devices. And, it is not feasible or cost-effective toemploy the existing addressing techniques into certain devices orcertain environments.

Historically, almost all devices which have been attached to a TCP/IPnetwork have been computer systems of some type, either of a‘conventional’ (with keyboard and display) or ‘embedded’ (such as anetwork printer) type.

In order to make a TCP/IP device functional on a network, it isnecessary to assign certain address parameters, most importantly the32-bit IP address. In many cases additional parameters such as netmask,gateway, and Domain Name Server settings also need to be established.These settings are important for proper performance otherwise thenetwork becomes unstable and exhibits erratic behavior affecting theperformance not just of the device being configured, but also otherdevices on the network.

The typical sequence for manual assignment of the IP address and othernetworking parameters begins with the direct assignment of the IPAddress using a local data entry port prior to attachment on thenetwork. This is normally accomplished through the operator panel oruser interface. The operator assigns the IP address by keystroke andconfirms the settings before allowing communication on the network.

One method of automatic assignment of IP addresses uses BOOTP or DHCP.The BOOTP or DHCP techniques require that a database be maintainedseparately that associates the ‘MAC address’ of the device to beattached with the required IP address and other parameters. Thisdatabase is created and maintained by the network specialist andrequires considerable skills that would not be held by the typical fieldreplacement technician. In addition, DHCP cannot be used conventionally,to assign an ‘unpredictable’ address within a ‘pool’ of availableaddresses, because the primary network protocols between industrialdevices, such as Modbus/TCP, use explicit knowledge of the IP addressesof the designated targets. For example, when DHCP is used on systemsusing Windows NT Server, the option known as ‘IP address reservation’ istypically used. This actually makes DHCP equivalent to BOOTP in thisembodiment.

This BOOTP or DHCP technique uses a central BOOTP or DHCP server tomaintain a list of MAC addresses and IP addresses in a central locationand allows access by the experienced network or system administer tomanage the lists. Although this protocol is implemented by many devices,the assignment must be done by the IS department or systemadministrator. In a factory environment with automated devices running24 hrs a day×7 days a week, employing a system administrator to assignIP addresses on devices around the clock is not cost-effective. Thetechnician or engineer replacing the device does not possess theadequate skill or knowledge to also assign the IP address, and having adevice failure may cripple the plant operation. Businesses must minimizethe downtime associated with field replacement of devices in order tomake the production numbers. Delaying a factory line until a systemadministrator can issue an IP address to the device is not asatisfactory option in the highly competitive marketplace.

Another system of assigning IP addresses is done via indirect assignmentusing static address resolution protocol (ARP) override. The device isdesigned to ‘assume’ that any IP message arriving at the device thatincludes a MAC address that matches that of the device implies theregistration of the IP address in the target. This forces the IP addresssent to the device to be adopted by the device even if it is already inuse. It also requires matching of the MAC address to the particulardevice. As noted herein, forcing the wrong IP address to a device on thenetwork can result in unexpected catastrophe.

Typically the ARP override method involves an operator sequence at amanagement station such as:

-   -   arp-s 10.0.0.1 00:00:54:ab:cd:ef    -   ping 10.0.0.1        This forces the local station to build a directed unicast        message to the Ethernet address 00:00:54:ab:cd:ef and designate        the IP address as 10.0.0.1. This is interpreted by the device        with address 00:00:54:ab:cd:ef as authority to assign the IP        address 10.0.0.1. Any internet protocol can be used during the        second phase. Instead of PING, it is common to use TELNET on        obscure port numbers in an attempt to avoid ‘accidental’        reconfiguration.

There are also alternative network protocols for devices, such as HPJetDirect cards. The HP JetDirect cards use the IPX protocol toadvertise their presence to any management station on the local network.A management program running on some station on the local network picksup the advertisement and displays the device as requiring configurationto the operator. Since typically only one station at a time on a networkwill be in an unconfigured state, this allows the operator to recognizeand select that unconfigured device without recording the MAC address.All of these mechanisms require either knowledge of the MAC address ofthe device being attached, or at least specialized knowledge of thedesired network function of the device by an operator. Use of analternative protocol such as IPX will cause problems in use of thedevices in environments where these protocols are not supported.

All the referenced techniques of IP Address assignment require eitherknowledge of the MAC address of the device being attached, specializedskills and training, or preferably both. IPX protocol implementationshave some further inherent difficulty with devices not supporting IPXprotocols on the network.

Industrial control devices pose particular problems because of theimportance of operation, continuous operation, and location of thedevices. These devices may fail in service and must be replaced rapidlyfrom a spares stock with minimum Mean Time To Repair (MTTR). Forexample, the devices may fail because they are exposed to electrical ormechanical stresses that exceed their specifications. An example of amechanical stress is being crushed by impact with a fork lift truck. Acommon example of an electrical stress is 110/220 V line power beingshorted to low voltage input circuits. In such situations, the devicesare usually designed to ‘go safe’, but they need to be replaced asrapidly as possible in order to allow the process to continue.

Most industrial users maintain a stock of spare devices of each typethat need to be replaced. These users provide instructions tomaintenance personnel for replacement of faulty devices. However, theneed to assign IP addresses accurately under such critical replacementconditions is usually not practical. This is particularly true inindustrial environments with strict responsibility partitioning betweenan electrician who can rewire a module, but requires the service of anIT technician to alter network parameters.

Previously, Ethernet was not considered a viable option to the businesscommunity. One problem with the implementation of Ethernet as areplacement for the device level networks such as ASi or DeviceNet wasthat you could not require anything more elaborate than the setting of arotary switch to match the predecessor device. Such problems diminishedas the protocols changed and expanded the Ethernet options.

One such protocol the industrial protocol MODBUS/TCP. MODBUS/TCP is acommunication protocol designed to allow industrial equipment such asProgrammable Logic Controllers, computers, operator panels, motors,sensors, and other types of physical input/output devices to communicateover a network. It was introduced by Schneider Automation in the early1990's as a variant of the widely used MODBUS protocol, which had beenimplemented in turn by almost all vendors and users of automationequipment. The specification of the MODBUS/TCP variant was published inorder to encourage all vendors to implement the protocol consistently,and thus avoid interoperability problems that typically result whenimplementors must ‘deduce’ or ‘reverse-engineer’ an interfacespecification.

There have been several attempts to resolve the aforementioned problems.One system automates the initial assignment of a process device addressby allowing a number of devices to be attached to the network, issuingqueries to which all devices will respond, and then using uniqueparameters or serialization included in those devices beforeinstallation to assist an operator in assigning the network address.

The mechanism of this system requires foreknowledge of the uniquecharacteristics of the device in order to provide address assignment,and cannot be used to perform automated assignment when replacing one ofpotentially many identical devices on a network segment. It is also notdesigned to work with TCP/IP local area networks. The mechanism ofassigning a temporary address first, and then using that to complete theconfiguration process, is only necessary when using networks which haveno native bootstrap address assignment process. In the case of a TCP/IPlocal area network, all of this functionality can be done using theInternet standard BOOTP protocol (RFC 951). With BOOTP, the informationneeded to perform the match is the serial number or ‘MAC address’ thatis uniquely associated with the network interface hardware and readilyavailable upon request.

Another system uses a technique which would most likely be banned in anypractical Internet TCP/IP local area network because it assigns anaddress for a device by using speculation. Specifically, it deduces therange of addresses in use on the network to which the device isattached, and then issues a series of queries to determine whether agiven address within that range has already been assigned to anotherdevice. The novelty of this system is that in addition to the standardARP technique ordinarily used to query the existence of a given IPaddress, this system extends this by issuing a series of ‘applicationlevel’ queries. The reason for doing this is to overcome problemsrelating to the ‘caching’ of ARP records.

A flaw in the this system is that it fails to address the case where theaddress being speculatively assigned has in fact already been assignedto another device, but that device is temporarily inaccessible, such asby being reset or through a temporary network disruption. The systemwould complete its assignment of the duplicate address in a finite timeperiod, after which, if the original device were to come back on line,there would be a duplicate address situation that would impede operationof the original device. This flaw supports the conclusion that it wouldlikely never be permitted on a network used for automation purposes, asmultiple devices with the same IP address would result in gravenetworking problems. A more appropriate solution to the assignment of anarbitrary address on a network is to use the Dynamic Host ConfigurationProtocol (DHCP) described in RFC 1531.

There is a further system that allows for the assignment of the networkaddress for a replaced device, automatically, by recognizing a unique‘logical identifier’, or an ‘arbitrary word, number, or combinationthereof’. One application of this system is the replacement of one ofmany identical devices on a network. Maintenance personnel set aplurality of switches or jumpers that are accessible on the device sothat they have an identical setting to that on the device beingreplaced. Once completed, the application technique completes thereplacement.

There are several limitations of technique of this system. Firstly, itrequires that the devices being replaced incorporate the capability ofreading some sort of ‘logical identifier’ before attempting addressassignment. Secondly, the devices being replaced must incorporate anon-standard protocol capability to transmit that information to themanagement device for the purpose of address assignment. These tworequirements severely limit the usefulness of the technique, sincenetwork administrators would be unwilling to deploy an automatedconfiguration technique unless it applied to a high proportion ofdevices likely to require such assignment. Any attempt to make therequirements into a standard would require agreement among multiplevendors of equipment to adopt this additional feature voluntarily. Suchcooperation would likely not succeed. The appropriate way of achievingsuch agreement is to propose the technique and get it adopted by astandards body such as the Internet Engineering Task Force (IETF).However, the IETF would be skeptical about the widespread adoption ofsuch a technique because of its similarity to the BOOTP and DHCPprotocols already available. In fact, the system describes a techniqueidentical to the BOOTP, where the logical identifier is the MAC address.

A system for allowing decentralization of a directory previouslymaintained on a single file server is also known in the art.Decentralization and resilience is achieved by arranging the ‘listservers’ to follow a defined protocol for determining the existence oflist servers on a network. And, updating their contents from one of thedevices whose contents are authoritative in order that any of thedevices can serve the information in the case of unavailability of theoriginal.

This technique has much in common with the distributed ‘Yellow Pages’database implemented on Sun Microsystems workstations dating back to themid 1980's. The primary difference is that the identity of a devicebeing available to take on directory service duties need not beconfigured in advance. Instead, the devices negotiate for authoritybased upon their assigned network addresses. This in turn is similar tothe procedure used by Microsoft in implementing the ‘automatic browsemaster assignment’ for Windows 95 peer to peer file service. Indeed,almost all of the described capabilities have an equivalent in the‘browse list’ feature maintained automatically by Windows 95 machines,and which is updated by notification messages sent out on a timed basisby network devices such as printers, computers, and other file serverdevices.

Similar to this system, there is another system that discloses amechanism that is concerned with assignment of an arbitrary networkaddress that allows the device to become functional on the network. Thisis accomplished by attempting to contact the existing devices that havebeen assigned the proposed addresses, in turn, until one is found thatis not currently assigned.

This latter mechanism is not appropriate for use on a TCP/IP local areanetwork because of the problems caused if the address in questionactually had been assigned to another device, but that device wastemporarily inaccessible. Such a situation would likely cause networkdisruption and possibly a failure of control in an automation system.Therefore, the methodology would not be acceptable on a network used forautomation purposes. Instead, the appropriate protocol to use if anarbitrary address were desired on a TCP/IP local area network is thestandard DHCP protocol described in RFC 1531.

Yet a further system describes a mechanism for more convenientallocation of addresses in a network environment that is not bound bythe address assignment conventions of TCP/IP. The techniques of thissystem are not appropriate for TCP/IP local area networks. Assigningappropriate address ranges for network segments which are subsequentlylinked together is cumbersome, and cannot generally be overcome bydefining an address assignment protocol that would be binding upon theexisting devices on those networks. The existing TCP/IP devices expectstability in address assignment, and the act of interconnecting twonetworks cannot by itself, cause reassignment of network addresseswithout knowledge of the devices themselves.

Other systems describe what is commonly called a network firewalltechnique to overcome an intended intrusion attack using ‘addressspoofing’. The firewall is pre-configured with an association betweenthe physical address of each subscriber device and the IP addressassigned to that device. The firewall recognizes the case where anincorrect source network address is being presented by an intrudingsystem, and prevents the messages from being propagated to theirintended target device.

Another system allows a general-purpose network to be used as part of abootstrapping mechanism to enter the initial configuration data for adevice after it has been physically installed on a network, but beforeit has been made operational. This mechanism is specifically unsuitablefor use with arbitrary target devices on a TCP/IP local area networksince it relies on assignment of a temporary network address, and anon-operational state known as ‘standby’, in order to allow the deviceconfiguration to be completed with manual assistance.

There is yet a further system that is similar to that used in manycommercially available network monitoring and system management tools,including ones which have been available on local area networks for morethan a decade. Passive monitoring of network traffic to determine theidentity and detail configuration of devices is a standard networkmanagement and troubleshooting procedure taught to network engineers.Building up a list of discovered devices in a database and displayingthe contents of such database on demand is a standard feature ofproducts such as 3Com Corp's ‘Transcend’ management package.

The technique of this system is not appropriate to the problem ofautomatic reassignment of network IP addresses when a target device isreplaced in service, because under those conditions there would be nobroadcast traffic to be monitored. In particular, use of Ethernetswitching devices on modern networks severely impedes the value ofpassive monitoring, since only messages designated as ‘broadcast’ or‘multicast’ are made available by the switches for monitoring by partiesother than the direct participants of the communication.

There is also a system concerned with gateway devices that must allowaccess to information using ‘foreign’ networks. Specifically, bydetecting the existence of one or more authoritative devices on theforeign network (the ‘target nodes’), and making queries upon them, thetarget nodes will divulge information which can be assembled by thegateway in order to ease the configuration of such gateway. Thisincludes pre-assignment of network address equivalence tables or similardata.

A method of allocating addresses on devices without using manualadjustment of switches is also known. This system does not use switches,relying instead on a known rearrangement of the wiring of an extensioncable or connector when connecting such devices in series.

Actually, this mechanism is akin to that used by Modicon Corp (now partof Groupe Schneider) on a product line known as ‘800 series I/O’introduced with the 884 model Programmable Controller in 1984. In thatproduct, the address of one of many modules in a modular I/O rack wasdetermined by a combination of its rack number and slot number withinthe rack. To allow the racks to be physically identical parts and yetdistinguishable in service, the interconnect cable performed a‘rotation’ of the assignment of 5 signals. The effect of this was thatthe signals being presented to modules in the individual racks weredetectable by the device, and this supplanted the need for any addressswitches.

Another existing system describes a technique similar to BOOTP, in whicha unique registration number known to the internet access device ispresented to a known registration service, which can be accessed withoutrequiring pre-configuration of the device, and obtaining anyconfiguration data from that device. The system relies on the existenceof a known network service access point on the Public Switched TelephoneNetwork, so the initial contact with the registration service can bedone using only a previously recorded telephone number and modemsettings. From that point onwards, any complex configuration settingscan be automated based upon details previously registered in thedatabase or negotiated with the equipment.

Devices that make use of this technique must be specifically designed todo so, because the protocols used are non-standard. The non-standardmechanism is required to handle the case where the device beinginstalled is not on the same local area network as the registrationserver. If it were on the same network, the same results could have beenobtained using the standard protocol BOOTP.

In sum, the problem with known systems is that they require involvementof a specialized administrator to oversee the part replacement in orderto properly configure the network address. The state of the art does nothave a simple yet disciplined method to automatically designate properIP addresses while maintaining the highest level of system integrity.What is needed is an automatic network address assignment system. Such asystem would decrease the mean-time-to-repair (MTTR) and allow for fieldreplacement of networked devices without incurring the expense of havinga network professional administer the address configuration. Ideally,such a system would use management information gathered from Ethernetswitches to deduce physical location information, using such informationto deduce the appropriate network address.

SUMMARY OF THE INVENTION

The present invention is a system for the automatic reconfiguration ofIndustrial Networked Devices. More particularly, the present inventionfacilitates the use of TCP/IP networks, such as Ethernet, as analternative for industrial fieldbus or device buses.

Accordingly, one aspect of the invention is to automate thereconfiguration of devices such as I/O modules, sensors, or transducersunder field replacement situations. In one embodiment this is achievedby combining available Internet standard techniques along with a systemmanagement software component. The latter is referred to as the‘management entity’.

The present invention encompasses various algorithms and softwarerunning on a standard computer, such as a file server or administrativeworkstation that periodically polls the status of network devices. Oneaspect of the invention is to detect a failed network device that hasbeen replaced, wherein the system automatically assigns the networkaddress of the previously failed device. In one embodiment, thecomputing means is a dedicated monitor system in the form of a networkeddevice that is installed in the same plant area and by the samepersonnel as the automation equipment it is supporting. Alternatively,the computing means encompasses functionality extensions to the managednetwork switches themselves.

Another feature of the invention is the prompt identification ofnetworked devices that have failed in service, so that maintenancepersonnel can be dispatched rapidly to effect the replacement. This is aconsequence of the constant monitoring of the devices over the network.

A further aspect of the invention is a simplified initial configurationand set-up of the replaced equipment by using physical port numbers on amanaged Ethernet switch rather than the less convenient MAC addressnumbers to identify the networked devices.

One of the distinctions between the present invention and many of theother systems is the use of management information from a ManagedEthernet switch to deduce physical location information or using thatinformation to deduce a network address. There is also no mention in theexisting systems of the use of information from a management entity on aManaged Ethernet switch or similar device to deduce the appropriatenetwork address to use when replacing a device.

The present system in one embodiment requires no change to the networkprotocol capabilities of the target device, other than that it supportthe standard BOOTP address assignment protocol. There is no need to makeaccessible external switches or similar mechanical means which can be asource of additional cost, complexity, and unreliability. Thedetermination that the device is an intended replacement, and thusshould be reassigned a previously recorded address, is obtained byautomated query to the management entity of an Ethernet switch orsimilar device to which the network cable is connected. The act ofconnecting the new device to the same cable or port as the original oneprovides the equivalent function to the ‘logical identifier’ in theprevious patent.

The mechanism for obtaining the network address information for oneembodiment of the present invention is via the standard ARP protocoldescribed in RFC 826. The present invention interrogates the existingtarget devices themselves after having determined that the device isamenable to automated maintenance by querying a managed Ethernet switchor similar device and confirming that the device in question is in anarea of the network that has been pre-configured for such automatedmaintenance.

One embodiment of the present invention allows unmodified TCP/IP targetdevices, implementing only the address assignment protocol BOOTP to beconfigured without human assistance, and it deduces the addressassignment using information from a standard managed Ethernet switch.

One embodiment of the present invention uses location data obtained froma managed Ethernet switch or similar device to confirm the equivalenceof a newly installed device to its failed predecessor, and allows thecommunication of the new IP address using the standard BOOTP protocol.

The present invention in one embodiment performs the IP addressassignment of a replacement device, and uses physical location dataobtained from a standard managed Ethernet switch to provide guidance forsuch network IP address assignment.

One embodiment of the present invention is not concerned with operatinggateways to foreign networks. The address information that needs to bemaintained in order to perform IP address replacement is obtainedwithout the assistance of designated target devices from which theaddress information can be obtained. Rather, address information isdeduced using physical location information maintained by the standardmanaged Ethernet switch equipment for the benefit of human operators.There is no known system in which the use of physical location dataobtained from a standard managed Ethernet switch to provide guidance fornetwork IP address assignment when replacing devices in the field.Likewise, there is no relevance of the existing techniques to thereassignment of network IP addresses in a TCP/IP local area network.

One embodiment of the technique of the present invention allocatesreplacement IP addresses for standard TCP/IP target devicesautomatically, communicating them to the device using the standard BOOTPprotocol. The address assignment is determined with the assistance ofmanagement information obtained from a standard managed Ethernet switchsupervising the network.

The present invention benefits from the standards relating to RFC 951Bootstrap Protocol (BOOTP) and RFC 1493 SNMP support for Ethernet switchdevices, in addition to RFC 2108. By using the international standards,all devices under the standard respond in the same manner. The presentinvention combines these widely implemented standards with uniquemethods and along with a novel software management entity to supervisethem. As DHCP is compatible with BOOTP, if the query is determined to beDHCP, the DHCP form of the BOOTP response can be used.

A further feature of the present invention is that the network may bedeployed in such a way that every target IP unit has a dedicated line toa port on a managed switch. In this case, there are no issues ofambiguity of replacement unit identity. Alternatively, the managedswitches may be deployed on a more selective basis and utilize lessexpensive unmanaged switches or repeating hubs as the interface for thetarget IP units. In this scenario, the managed switch encounters morethan one MAC address associated with one managed port on a switch. It istherefore necessary to restrict auto-reassignment of addresses to thecase where the number of failing target IP units in the given managedplant area is exactly one.

One of the benefits of the present invention is the ability to recognizefailed networked devices and automatically assign correct IP addressesto diminish down-time. Additionally, the methodology locates thephysical location or region of the networked devices allowing for easeof finding a failed device. The present invention, in some embodiments,also deals with the authority of the system to assign IP addresses onlyif a single unit is determined to be replaced, wherein if the systemcannot isolate to a single failed network device, the automaticassignment can be suppressed.

An embodiment of the invention includes a system for field replacementof networked devices, comprising the steps of detecting a failednetworked device, replacing the failed networked device with afunctioning networked device, locating a canonical location of thefunctioning networked device, issuing an IP address to the functioningnetworked device, wherein the IP address is identical to the IP addressof the failed networked device.

A further aspect includes the step of detecting the failed networkeddevice which is accomplished by a unicast ARP request. Additionally, thestep of detecting the failed networked device can be accomplished byperiodic ARP requests. A feature also includes a system, wherein thestep of detecting a failed networked device comprises processing aplurality of ARP requests over a time period before indicating thefailed networked device. In addition, notifying maintenance personnel ofthe failed networked device is a further aspect.

Another aspect of the system includes, wherein the step of locating acanonical location of the functioning networked device comprisesrequesting a MAC address for the functioning networked device andrequesting a port number for the MAC address from a managed switchingdevice, wherein the port number so returned, in combination with theaddress of the managed switching device, is the canonical location ofthe functioning networked device.

Another feature is locating a canonical location of the functioningnetworked device comprising identifying a plurality of target devices atthe canonical location, comparing the canonical location of thefunctioning networked device with a database containing information ofall the networked devices to isolate a single failed networked device atthe canonical location. The present invention includes the step ofsuppressing the issuance of an IP address to the functioning networkeddevice if unable to isolate to a single failed networked device.

Another embodiment of the invention is for a method for determining acanonical location for a plurality of networked devices, comprisingmaintaining a list of IP addresses for each of the plurality ofnetworked devices on a monitor agent. Identifying the MAC address fromthe request message issued by a network device requesting an IP address.Maintaining a list of MAC addresses for each of the plurality ofnetworked devices on the monitor agent. Requesting and retrieving a portnumber on a switching device for each MAC address. Maintaining a list ofport numbers and switching device addresses for each of the plurality ofnetworked devices on the monitor agent. Processing the canonicallocation for each of the plurality of networked devices.

Additionally, a feature includes, wherein the switching device is amanaged switching device and the port number is dedicated to thenetworked device and is the canonical location. Alternatively, theswitching device may be an unmanaged switching device and the portnumber is shared among a plurality of target devices.

An embodiment of the invention is a method for detecting a canonicallocation for a failed network device, comprising requesting a logicaladdress or MAC address for each of a plurality of networked devices.Detecting the failed network device and processing the logical addressfor the canonical location of the failed network device. Finally,logging the logical address, the canonical location, and an IP addressfor the failed network device. Another feature includes the step ofdetecting the failed network device based on no response from therequesting step.

An object includes a method, wherein the step of processing the MACaddress for the canonical location comprises accessing a databasecontaining a MAC address listing, an IP address listing, a switchingdevice IP address listing, and a port listing for each of the pluralityof networked devices, and wherein the combination of a switching deviceIP address and a port number represents the canonical location of thefailed network device.

Yet another object is a method wherein the step of processing the MACaddress for the canonical location comprises accessing a databasecontaining a MAC address listing, an IP address listing, a switchingdevice IP address listing, and a port listing for each of the pluralityof networked devices, and wherein the combination of a switching deviceIP address and a port number represents the canonical location of aplurality of target devices, and the IP address of the failed networkdevice is determined by locating a single failed target device at thecanonical location.

An object of the invention is an apparatus for the automaticconfiguration of networked devices, comprising a network interfaceinterconnecting the networked devices, a means of detecting thenetworked devices, a means of determining a canonical location of thenetworked devices, and a monitor agent connected to the networkinterface, wherein the monitor agent issues an IP address to each of thenetworked devices and records a MAC address for each of the networkeddevices and wherein the monitor agent maintains a list of each IPaddress and each MAC address.

One embodiment is a method for determining the correct logical addressto assign to a target network device, comprising maintaining a list ofassignments of logical addresses, possibly on a monitor agent, whereinthe list associates the logical addresses with both a network physicaladdress and a canonical location. The canonical location is generally acombination of both the logical address of a managed network switch andthe port number of the switch used for communication with the targetnetwork device. Receiving a request from the target network device forthe correct logical address, wherein the request generally provides atarget network device physical address. Searching the list ofassignments for a match of the target network device physical addressand if there is a match, the correct logical address is provided to thetarget network device.

If there is no such match, the method further comprises interrogating atleast one managed network switch on the network to request the portnumber associated with the target network device physical address andderiving a canonical location from the logical address of the switchingdevice and port number. Searching the list of assignments for acanonical location match and providing the correct logical address uponthe canonical location match.

The interrogation may include requesting each managed switch to reportwhether the switch observed messages originating from the device withthe physical address, and if so, identifying the port of the switch onwhich the messages were last observed. Receiving responses from one ormore of the managed switches, each such response identifying a logicaladdress of the managed switch and a port number of the switch on whichthe recently observed messages originated from a device having thephysical address, such combination of the logical address of a managedswitch and a port number being considered a canonical location.Consulting the list of assignments to see whether one or more of theentries in the list has a match for the canonical location, if there isa match on the canonical location, and if there is only logical addressthat has such a match, then the determination is complete, the resultbeing the logical address in the referenced entry in the list.

Still other embodiments and advantages of the present invention willbecome readily apparent to those skilled in this art from the followingdetailed description, wherein only a few embodiments of the inventionare described, simply by way of illustration of several modescontemplated for carrying out the invention. As will be realized, theinvention is capable of other and different embodiments, and its severaldetails are capable of modifications in various obvious respects, allwithout departing from the invention.

The features and advantages described herein are not all-inclusive and,in particular, many additional features and advantages will be apparentto one of ordinary skill in the art in view of the drawings,specification, and claims. Moreover, it should be noted that thelanguage used in the specification has been principally selected forreadability and instructional purposes, and not to limit the scope ofthe inventive subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a basic block diagram showing interconnected elementsconfigured in accordance with one embodiment of the present invention.

FIG. 2 is a block diagram illustrating replacement situation configuredin accordance with one embodiment of the present invention.

FIG. 3 is a diagrammatic perspective of discovery/confirmation for adedicated port configured in accordance with one embodiment of thepresent invention.

FIG. 4 is a diagrammatic perspective of discovery/confirmation for ashared port configured in accordance with one embodiment of the presentinvention.

FIG. 5 is a diagrammatic perspective of confirm presence for a dedicatedport configured in accordance with one embodiment of the presentinvention.

FIG. 6 is a diagrammatic perspective to confirm presence of a sharedport configured in accordance with one embodiment of the presentinvention.

FIG. 7 is a diagrammatic perspective of IP Address assignment configuredin accordance with one embodiment of the present invention.

FIG. 8 is a diagrammatic perspective of IP Address reassignmentconfigured in accordance with one embodiment of the present invention.

DETAILED DESCRIPTION

One embodiment of the present invention is referenced in FIG. 1. Thereis a monitor agent 10 that serves as the BOOTP server and comprisescomputing means for managing and processing the network data and amemory means for storing information. The monitor agent 10 is connectedto a network having one or more managed switches 20. The managedswitches 20 are considered to be on the local plant area. There aremultiple ports 25 on the managed switch 20, and it is capable ofreporting MAC addresses and/or port assignments.

In one embodiment, the TCP/IP network is Ethernet and uses Ethernetmanaged switches 20. It should be understood that the term networkrefers to any communication exchange and not a specific type ofconnection.

Connected to the managed switch 20 are a number of inexpensive hubs 40with a number of hub ports 45. Connected to these hub ports 45 are aplurality of devices, such as I/O devices 50 and other elements such asa computer 60.

Each device connected to the hub ports 45 has an associated MAC addressand an associated IP address. The managed switch 20 reports all MACaddresses and port assignments associated with the hubs and devicesconnected to the monitor agent 10. The monitor agent 10 maintains a listof all port assignments and MAC addresses. Thus, not only does themonitor agent 10 know the MAC and IP addresses of an individual device,but it also knows the approximate location by knowing to which port of aManaged Ethernet Switch 20 the device is connected.

The local plant area refers to the system of devices located from amanaged Ethernet switch 20 and downwards, including all hubs and I/Odevices interconnected therein. The monitor agent 10 exists in anenterprise net, and records all IP and MAC combinations found in thelocal plant area.

Referring to FIG. 2, each of the working devices 70, 80 connected to thehub 40 has a MAC address and an IP address. The failed or malfunctioningunit 100 also had a MAC address and IP Address. Based on periodic devicepolling, the information of a failed unit has already been communicatedto the monitor agent 10 through the managed switch 20. The monitor agent10 also lists the failed device 100 as being located on managed switchPort 1.

From an overview perspective, as soon as the failed device 100 isreplaced with a working device 110, the working device 110 requests anetwork assignment. The monitor agent 10 notes the request, anddetermines if the request originates from the location of the previouslydetected failed unit 100. If the request comes from Port 1, the monitoragent 10 issues the same IP address as the previous device and the newdevice 110 begins operating on the network.

More specifically, the monitor agent 10 maintains a database of all MACaddresses for each device on the network. This BOOTP database is builtand maintained automatically, by the monitor agent 10 that takesadvantage of the MAC address detection scheme built into modern Ethernetswitch devices. Using this capability, which is referred to as the SNMPFindPort query and is defined by RFC 1493, it is possible by issuingSNMP requests from a management program to track down a particular MACaddress and identify on which port of which switch it is found.

The IP addresses of the various devices are also maintained by themonitor agent 10. Actually, the monitor agent 10 issues the IP addressto each new device. In operation, all devices are set to request theirnetwork assignment, or IP Address, at power up using the standard BOOTPprotocol. In one embodiment, the devices perform the request multipletimes, such as 3 or more, over a ‘reasonable period’ such as 15 seconds.If a response is obtained from a BOOTP server entity on the network,then the IP address and other returned parameters will be used by thedevice. In addition, the IP address information may be recorded locally,so that in the event that the device subsequently powers up WITHOUT theBOOTP server being available, it will fall back to the last known goodaddress.

If the device has an address recorded already, and the address returnedusing BOOTP is different, then the newly obtained address is used andrecorded. The present invention thus handles the case where a unit isswapped out, tested, found to be operable, and returned to spares stock,but it has not been completely initialized in the process.

MAC addresses are conventionally expressed as a hexadecimal number with12 digits, in the form ‘ab:cd:ef:01:23:45’. The expressions ‘ABC’, ‘DEF’etc in the figures are a simplification to avoid distracting the reader.Referring again to FIG. 2, as an example−a first I/O device 70 has a MACaddress=ABC, a second I/O device 80 has a MAC address=DEF, and a thirdI/O device 100 has a MAC address=EFG. The MAC addresses were previouslydetected and recorded by the monitor agent 10. The monitor agent 10 alsorecords and issues the IP addresses for each device. Thus, first I/Odevice 70 has an IP address of 10.0.0.1, the second I/O device 80 has anIP address of 10.0.0.2, while the third I/O device 100 has an IP addressof 10.0.0.3. The monitor agent 10 identifies each of these I/O devices70, 80, and 100 as coming from Port 1 of the managed switch 20.

The monitor agent continually polls the I/O devices 70, 80, 100, andwhen a device malfunctions, the device either issues commands indicatinga failure, sends back a malfunction or error code in response to thepoll, or ceases to respond at all. The failure information can beforwarded to the appropriate maintenance department. In the presentexample, device 100 fails.

Once the maintenance personnel have successfully removed the faulty unit100 and installed a replacement device 110, the replacement device 110issues a BOOTP request. The monitor agent 10 receives the BOOTP requestand determines if the managed switch 20 port location of the replacementdevice 110 coincides with the location of the present BOOTP request. Ifthe monitor agent 10 determines that the replacement device 110 isreplacing the malfunctioning device 100, it issues the same IP addressto the replacement device 110.

For example, the replacement device 110 with a MAC address of HIJ issuesa BOOTP request which is transmitted through the hub 40 port 3 andthrough the managed switch 20 port 1 to the monitor agent 10. Themonitor agent determines which port of the managed switch the BOOTPrequest originated. Once it is determined that the failed unit and theBOOTP request came from the same port of the managed switch 20, thereplacement device 110 is designated with the same IP address as thefailed unit 100 and assumes the IP address 10.0.0.3. The replacementdevice 110 is thus quickly established on the network. The monitor agent10 then continues to poll the units for status.

In one embodiment, a managed switch is used in lieu of the hub 40, sothat the monitor agent 10 can track the port designations from eachlayer of the network. In another embodiment, the monitor agent itselfmay be duplicated on the network, so that in the event of failure of thehardware or networking infrastructure leading to the monitor agent 10,another monitor agent with visibility into the same local plant areawould be able to take over its duties.

The discovery/confirmation sequence finds the MAC address of targets andrecords the canonical location (numbered port of supervised switch) fora dedicated port scenario as shown in FIG. 3. The discovery sequencedetects initial or new devices connected to the network and confirms thetarget locations. The supervisor/monitor agent 200 issues an ARP request210 as a broadcast message to inquire the MAC address of the IP address.The target IP unit 220 receives the request and issues an ARP response230 containing the MAC address of the requested IP address.

The supervisor 200 issues an SNMP Findport request 240 to the managedswitch 250 to request the port number of the reported MAC address. Themanaged switch 250 issues an SNMP Findport response 260 back to thesupervisor 200 with the port number of the MAC address. In FIG. 3, portnumber 3 would be returned to the supervisor.

FIG. 4 shows the discovery/confirmation sequence for the shared portscenario. In this embodiment, the supervisor 200 issues a broadcast ARPrequest 210 to inquire the MAC address of the selected IP address. Thetarget IP unit 220 responds with an ARP response 230 containing the MACaddress of the requested IP Address. The supervisor 200 then issues anSNMP Findport request 240 requesting the port number of the MAC address.The managed switch 250 issues an SNMP Findport response 260 back to thesupervisor 200 with the port number of the MAC address. In FIG. 4, portnumber 3 would be returned to the supervisor.

However, the managed switch 250 connects to one or more unmanagedswitches or hubs 300. Multiple target units 220, 310, 320 are connectedto the unmanaged switch 300. Thus indicating port 3 of the managedswitch indicates the target units 220, 310, 320 as sharing the managedswitch 250 port 3. Automatic reallocation would be suppressed andfurther processing would be required to determine which of the targetunits 220, 310, 320 is down, if more than one of them were down at thetime of attempted replacement.

The confirm presence sequence interrogates the target units at periodicintervals, whereby a non-responsive unit indicates the target is ‘down’or failed. In a dedicated port scenario such as shown in FIG. 5, asingle target down in a canonical location becomes a reassignmentcandidate.

During the confirm presence process, the supervisor 200 issues an ARPrequest 210 as a unicast message to inquire the MAC address of aselected IP address. If the target IP unit 220 receives the request andreturns an ARP response 230 containing the MAC address of the requestedIP address, the unit is determined to be functioning. If there is noresponse, this indicates that the target IP unit 220 is down or failed.Such a failure isolates the reassignment candidate to a single unit forthe maintenance personnel. Note that the supervisor can be programmed toperform the check a certain number of intervals over a certain period oftime before determining the unit failed. Such repetition and timeintervals are usually specific to the application, and it would beobvious to one skilled in the art to change the repetition or timing.

FIG. 6 shows the confirm presence sequence for the shared port scenario.In this embodiment, the supervisor 200 issues an ARP request (unicast)210 to inquire the MAC address of the selected IP address. The target IPunit 220 responds with an ARP response 230 containing the MAC address ofthe requested IP Address. If no response is returned, the target unit220 is down and selected for reassignment. If there is only a singletarget unit on the unmanaged switch or hub 300 for which a failure isindicated, then the single target unit is down and selected forreassignment. However, where there are multiple target units 220, 310,320, and more than one of them are down, then the automatic reallocationis suppressed.

For example, the managed switch 250 connects to one or more unmanagedswitches or hubs 300. Multiple target units 220, 310, 320 are connectedto the unmanaged switch 300. Thus indicating port 3 of the managedswitch 250 only indicates the target units 220, 310, 320 as sharing themanaged switch 250 port. Additional processing is necessary to determinewhich target IP unit has failed.

The normal use of ARP request messages is to inquire the MAC address ofa target whose MAC address is not known but whose IP address is known.In order to send a unicast message the sender must designate the MACaddress of the target. The use of unicast ARP requests during therepetitive ‘poll’ of the device confirm whether the device is stillalive. The choice of a unicast rather than a broadcast for thisinterrogation is important in large networks to avoid excessive use ofbroadcast traffic that will be perceived as needless interruption by allother stations.

FIG. 7 shows the IP address assignment sequence to automatically issuean IP address to a target unit that was reset or power cycled, butotherwise previously running at that location. The target IP unit 220automatically broadcasts a BOOTP request 400 to supply an IP address forthe MAC address. The supervisor 200 receives the BOOTP broadcast andsends out an SNMP Findport request 410 to the managed switch 250,requesting the port number for the MAC address. The managed switch 250responds with an SNMP Findport response 420 with the port number for theMAC address. In this example, the port number was 3 for the MAC address.The supervisor 200 checks if the MAC address was already associated withthe IP address at that canonical location. If the MAC address matchesthe number which the supervisor 200 expected, the supervisor 200 issuesa BOOTP response 430 and sends the IP address for the MAC address.

The IP address reassignment sequence is shown in FIG. 8. The target unit440 was not previously running at that location, and issues a BOOTPrequest 400 as a broadcast message. The supervisor 200 receives theBOOTP request 400 and issues an SNMP Findport request 410 to find theport number of the MAC address. The managed switch 250 receives therequest 410 and replies with an SNMP Findport response 420 that containsthe port number of the MAC address. The supervisor 200 determines thatthe MAC address is unknown.

In the illustrated embodiment, a single unit 440 at that location is notresponding. The supervisor 200 updates the equivalence table that linksthe IP addresses, and records the new IP assignment and authorizes theassignment. The supervisor 200 issues a BOOTP response 430 that sendsthe IP address to the requesting device at the new MAC address. It isassumed that the target unit 440 is an equivalent unit 440 and connectedwith the same cabling.

In operation, the management program/supervisor, as part of a routineperiodic ‘scan’, determines the existence of the networked devices. Themanagement program/monitor agent interrogates the network switch anddetermines the location of the devices on the network. The device iseither a single device attached to a network switch port (on a fullyswitched layer 2 network) or being one of a limited number of deviceslocalized to a single port on a switch. The hubs that are not managedare less expensive, but do not provide an exact resolution as to whichport the devices within the hub are connected. This latter method is amore economical hybrid of managed switches and unmanaged switches orhubs. In addition, the management program has authority to interrogatethe devices in benign ways, such as PING or attempted Modbus/TCPconnection, to confirm the identity of the device as far as therelationship between MAC address and IP address.

In practice, the interrogation is done by running a routine ‘probe’ ofthe address space domain. For example, the management entity may issue aModbus/TCP connection attempt to each device. Any station or device thatacknowledges the connection request is recorded as being a potentialaddress management candidate, and the details are recorded as follows:

-   1. The IP address is known and it was the one used in the probe.-   2. MAC address is obtained by checking the local ARP table or by    recording the source MAC address of the acknowledgement response.-   3. Find switch and port assignment by comparing the MAC address with    the most recent FindPort response record obtained from the switches    on the network. Alternatively, the switch and port assignments are    found by issuing an exploratory sequence of FindPort requests to the    switches in the hierarchy. The values corresponding to the ‘most    local’ switch to the device are recorded. This information is then    used to prepare the BOOTP database as well as a MAC/location lookup    table.

Once the device has been detected using the probe, it is added to a listof devices whose operability is to be continuously monitored. This maybe done in a variety of ways such as checking on a frequent basis thatthe device is still responding, and confirming the MAC/location data. Ifa device is found to be unavailable, that physical switch/portcombination will be monitored closely for reappearance of the samemodule or for a potential replacement operation. The unavailability canbe logged according to a length of time or number of requests. Analerting signal can be issued to maintenance as part of the overallconfiguration.

Under most situations, such as a routine shutdown and restart of theplant area concerned, the original device will repeat its BOOTP requeston powerup. The management entity will find a match of the requested MACaddress in the BOOTP table, and will send back a BOOTP response to thedevice authorizing it to use the IP address previously recorded. Thusthere is minimal delay on normal plant reset operations.

If a device needs to be replaced under field maintenance conditions, thedevice is replaced quickly and by a low-level technician or maintenanceperson. The replacement device is connected to the same network cable asthe former unit, or at least, to the same port on the switch. It isimportant to note that the replacement device must be an equivalent unitto the failed unit and operate with the same functionality and commandset.

Once the replacement unit powers up, it issues a BOOTP request, asdictated by the industry standards. There will not be any ‘conventional’ BOOTP server with the MAC address of the device in its database, sothere will not be any conventional BOOTP response. There will be noentry in the management entity's database. At this point the managemententity will contact the switches which it is monitoring to find whichone ‘saw’ the MAC address of the BOOTP request it just received. Ofcourse, the switches it consults first are the ones that are known tohave one or more ‘missing’ devices on the most recent update scan.

If a switch returns a match with the MAC address of the BOOTP request:AND; The management entity confirms only a single device was missingfrom the set of devices monitored at that switch port: AND; The deviceappears to be similar to the device that was missing: AND; The devicehas not apparently been assigned an IP address already (for example, ithas made multiple BOOTP requests): THEN; The management entity willauthorize the substitution of the single ‘missing’ IP address to thedevice now requesting. A BOOTP response is sent back (after the secondor third BOOTP request, not the first) which the device will interpretin the normal way.

As a result of this automated field replacement, a single TCP/IP stationis performed automatically, without manual configuration, and it is donein less than 15 seconds.

With respect to deliverable and management, the management entityrunning in one or more computers should be available 7 days a week×24hours a day. The most natural such devices are the managed Ethernetswitches themselves. They ordinarily are supplied with uninterruptiblepower, and are designed to have a very low likelihood of failure. Inaddition, because the present invention does not rely on a uniquedatabase, such as DHCP, there is no issue with two or three devicessharing the responsibility for network supervision.

The devices in turn would be configured in some convenient way, such asvia an embedded Web server, to be advised of their ranges of IP addressto monitor and if there are any special distinguishing characteristicsof particular parts of the network. In particular, information such asthe IP addresses of the switches to be supervised are most convenientlyentered in this way, rather than having to be ‘discovered’ throughnetwork probing techniques. Most importantly, the configurationinformation is entered by personnel who have familiarity and authorityto manipulate network addresses.

An additional embodiment allows direct entry to the management entity ofthe desired network address of a new module on a given switch port. Thiscan be used as part of a controlled installation sequence, where thetechnician inputs the data one entry at a time, in step with powering onthe modules. This avoids the need, common today, for the technician torecord the MAC address from the module and enter it as part of aconfiguration sequence. Instead, the technician performs the followingsteps:

-   -   1. Select the switch and port to which he wants to attach the        module    -   2. Confirm that there is no currently ‘missing’ module on that        port    -   3. Enter the desired IP address as if it were a ‘missing’ module    -   4. Allow the newly attached module to power up.

This allows the single module to be assigned, and the technician can goon to the next maintenance task. This is much more convenient than anycurrent technique in the industry.

The present invention works extremely well in environments where thelocation of a device can be determined accurately. For example, where afully switched layer topology is used and there is an RFC 1493management at the local switch allowing resolution to a single device ona port.

If, however, more than one device is ‘down ’ on a network segment, andthe address cannot be matched unambiguously, it is not safe to transformautomatic address substitution in this manner. In such a situation, itis not known which of the multiple devices requires substitution.

This situation is improved at minimal increase in complexity by allowingthe devices to alter one of the fields of the BOOTP request in such away as to have a different ‘signature’ based upon device type. Forexample, all devices from a given manufacturer and family might share acode, but the code varies between, a 16-point discrete output module anda 4 channel analog input. By using this auxiliary information in itsBOOTP equivalence table, the management entity is able to reduce theincidence of ‘reassignment stall’ situations. This technique wouldrequire cooperation and standardization in the industry to be effective.

One of the most obvious uses of the present invention is for deviceswithout operator interfaces, such as industrial I/O modules. However, itcan also be used to shorten the installation time for devices that dohave such interfaces, but where the IP address that is to be assignedmust be tightly controlled by a monitor agent.

For example, a ‘thin client’ computer to be used as an operator terminalcan be configured to use BOOTP. In the event of failure, a unit could bedisconnected and its replacement automatically assigned exactly the sameIP address. This is important in two situations common to computers onindustrial networks.

The first situation arises when the IP address is going to be validatedby ‘firewall’ devices, which must be convinced of the legitimacy of therequester by its physical location. Most firewalls can be configured toallow connections to ‘pass through’ based upon rules involving the IPaddress or range of IP addresses of initiator and target.

A second situation arises when a thin client has an active role on thecontrol network, and the act of replacing a device, and auto-assigningits address, allows the device to complete its ‘application bootstrap’by being given its application program and operating parameters fromsome anonymous server. This is particularly valuable in a ‘distributedcontrol’ environment where a component such as a PLC or gateway hasfailed, but could also apply to operator panels, robots, and similardevices.

Although BOOTP protocol is the most commonly used for automaticassignment of IP addresses, DHCP and RARP are obvious alternativeprotocols to respond to an address assignment request as describedherein.

Similarly, the interrogation messages sent out by the device to confirmthe continued presence of the target IP addresses can be either an ‘ICMPECHO’ (PING) request or simply a repeat of the ARP request used todetermine the identity in the first place. For efficiency purposes theinterrogation message is restricted to the ARP message, the message issent out as a unicast message, and sent only to the MAC address whichthe recipient used.

As will be realized, the invention is capable of other and differentembodiments and its several details are capable of modifications invarious obvious respects, all without departing from the essence of theinvention.

The foregoing description of the embodiments of the invention has beenpresented for the purposes of illustration and description. It is notintended to be exhaustive or to limit the invention to the precise formdisclosed. Many modifications and variations are possible in light ofthis disclosure. It is intended that the scope of the invention belimited not by this detailed description, but rather by the claimsappended hereto.

1. A method for determining a correct logical address to assign to atarget network device on a network, comprising: maintaining a list ofassignments of logical addresses for a plurality of networked devices,said list associating said logical addresses with a network physicaladdress and a canonical location; receiving a request for said correctlogical address from the target network device, wherein said requestincludes a target network device physical address; searching the list ofassignments for a target network device physical address match, andproviding the correct logical address to the target network device uponfinding said target network device physical address match; if no saidtarget network device physical address match is found from saidsearching, the method further comprising: interrogating at least onemanaged network switch on the network for a logical address and a portnumber associated with said target network device physical address andderiving a canonical location from said logical address and port number;and searching the list of assignments for a canonical location match andproviding said correct logical address upon said canonical locationmatch.
 2. The method according to claim 1, wherein said interrogatingcomprises requesting said at least one managed network switch to providesaid logical address and said port number based upon at least onemessage associated with the target network device physical address. 3.The method according to claim 1, wherein the logical address is anInternet protocol (IP) address and the target network device physicaladdress is a media access control (MAC) address.
 4. The method accordingto claim 1, wherein communications on said network are via a TCP/IPprotocol.
 5. The method according to claim 1, wherein the request fromthe target network device conforms to a protocol from the groupconsisting of: Bootstrap protocol (BOOTP) and Dynamic Host ConfigurationProtocol (DHCP).
 6. The method according to claim 1, wherein the requestto the managed switches conforms to the Simple Network ManagementProtocol (SNMP) protocol.
 7. The method according to claim 1, whereinsaid list is stored on a monitor agent, and wherein said monitor agentcomprises a computing device and memory.
 8. The method according toclaim 1, wherein the target network device is directly coupled to a portof the managed network switch identified by the canonical location. 9.The method according to claim 1, wherein at least one of said pluralityof network devices is coupled to a port of one or more unmanagedswitches or hubs, and a single logical address for the at least one ofsaid network devices is maintained in the list.
 10. The method accordingto claim 1, wherein at least one of said plurality of network devices iscoupled to a port of one or more unmanaged switches or hubs, and atleast one logical address for the at least one of said network devicesis maintained in the list.
 11. The method according to claim 1, whereinsaid searching the list of assignments for a canonical location matchreturns more than one logical address, the method further comprises:determining that there is only one not in service network device amongsaid more than one logical address, and said correct logical address isfrom said one not in service network device.
 12. The method according toclaim 11, wherein said determining is accomplished by transmitting amessage to each said network device among said more than one logicaladdress, and wherein a response indicates that the device is in service,and the absence of a response indicates that the device is not inservice
 13. The method according to claim 1, wherein said interrogatingis performed using a communications form selected from the groupconsisting of: Internet Control Message Protocol (ICMP), Packet InternetGroper (PING) message, multicast ARP REQUEST message, and unicast ARPREQUEST message.
 14. The method according to claim 1, further comprisingperiodically polling said networked devices to determine whether each ofthe logical addresses is currently in service.
 15. The method accordingto claim 14, wherein said periodic polling is selected from the groupconsisting of: ICMP PING, multicast ARP request, and unicast ARPrequest.
 16. A method for determining a canonical location for aplurality of networked devices, comprising: maintaining a list oflogical addresses for each of said plurality of networked devices on amonitor agent; processing a network device physical address for each ofsaid plurality of networked devices; maintaining a list of said networkdevice physical address for each of said plurality of networked deviceson said monitor agent; receiving a port number on a switching device foreach said network device physical address; maintaining a list of portnumbers for each of said plurality of networked devices on said monitoragent; and processing said canonical location for each of said pluralityof networked devices.
 17. A method according to claim 16, wherein saidmonitor agent comprises a computing means and a memory means.
 18. Amethod according to claim 16, wherein said switching device is a managedswitching device and said port number is dedicated to said networkeddevice and is said canonical location.
 19. A method according to claim16, wherein said switching device is an unmanaged switching device andsaid port number is shared among a plurality of target devices.